Networked computers are highly vulnerable to a class of attacks known as buffer overflow attacks. To exploit a buffer overflow, an attacker sends a message containing malicious code to a computer. This message is crafted to override an address pointer with the address of the interjected malicious code. In due course, the overwritten pointer is copied into the program counter of the computer's central processing unit (CPU). The CPU then executes the malicious code.
Buffer overflow attacks can create a back door for the attacker, transfer sensitive information from the system, destabilize the system, or open the system to use as a source node in a distributed denial of service attack. Buffer overflow attacks are common, easy to exploit, hard to eliminate, and potentially highly damaging when successful.
Common implementations of the memory subsystem of many operating systems (e.g., Unix, Linux, and Windows 9x/me/2000/NT/XP) are vulnerable to exploitation by network-based attackers. The memory subsystem of these operating systems fails to provide adequate facilities to ensure that unauthorized processes cannot access and alter memory.
One of the most common methods for attackers to gain unauthorized access to networked hosts is to introduce malicious code through externally accessible network services (e.g., through the Internet or an intranet). The attacker typically sends a message containing the malicious code to a server process. The message is crafted to overwrite a code pointer, causing the host CPU to jump to and execute the attacker's code. Since server processes typically operate with elevated privileges, the malicious code, when executed, usually has free rein on the compromised system to access information or create a back door for the attacker to access the machine at his convenience. Often, the malicious code will allow the use of the compromised system as a host for a secondary attack through the network. Many distributed denial-of-service attacks have been launched from large numbers of innocent machines that had been compromised in just such a way.
These buffer overflow attacks are too easy to launch. Of the Department of Defense Computer Emergency Response Team (CERT) advisories that describe attacks resulting in the attacker gaining elevated privileges on compromised systems, approximately 75% are buffer overflow attacks. Such attacks affect a wide range of server software running on an equally wide range of operating systems, both open source and commercial. It is not just server software that is vulnerable. Client software has also been successfully subverted in a similar manner by causing the processing of maliciously constructed web pages, mail messages, and/or data files.
Although developing code for a buffer overflow attack may require a certain amount of initial analysis and trial-and-error experimentation, once a suitable vulnerability has been uncovered in a piece of software, the means of exploiting it can easily be automated. Furthermore, the code developed is usually made freely available on the Internet. This makes the attack technique accessible to and usable by attackers with almost no technical sophistication.
Resistance to such attacks is desirable if an operating system is to be trusted. The traditional response to such an attack is reactive. That is, when vulnerability is discovered, the vulnerable software is patched to eliminate the vulnerability. This is an after-the-fact response, since vulnerabilities are often only discovered after a number of attacks have been detected. Also, this response is slow, as patches have an appreciable lead-time in their development and dissemination. Additionally, this post-attack patching approach offers no protection against vulnerable function calls that are not yet included.
Certain programming languages, most notably C and C++, are especially vulnerable to buffer overflow attacks. This is because these languages pass pointers and function return addresses over the stack. Unix and Unix-like operating systems are typically written in C. In these operating systems, fixed code resides in a “text” segment, fixed data resides in an “rodata” segment (which may be combined with the text segment), variable code and data reside in a “data” segment, and i/o buffers and the stack reside in a “bss” segment. The text and rodata segments are classed read-only. That is, the code and data contained in these segments generally cannot be altered from the outside. The data and bss segments, on the other hand, are classed as read/write. Code and data in these segments are therefore vulnerable to attack.
In a typical buffer overflow attack, the attacker introduces code into the memory space of the target system, then the attacker causes the CPU to execute the code. The most common means of accomplishing this is by subverting one of the many “daemon” processes present in modern operating systems. These are usually configured to both accept messages from the network, and operate at high levels of privilege. To illustrate a typical attack, consider a simplified example, where the daemon has a simple message-processing process that allocates one fixed-length buffer to store the incoming message. On entry, a stack frame contains a buffer/stack area in which the buffer grows upward and the stack grows downward, i.e., the buffer and stack grow towards each other.
Normally, a message is received and placed in the buffer. This message is then processed by a daemon whose return address is placed on the stack. In this case, when the daemon terminates, the return address is popped off the stack and loaded into the CPU program counter, and execution continues as normal.
Now suppose an attacker wishes to compromise the host on which the daemon is running. The attacker constructs a message longer than the reserved space in the buffer, containing some code, additional meaningless data to fill the remainder of the memory space, and a pointer to the code, designed to go exactly in the position of the return address.
The attacker has succeeded in “smashing the stack.” Now, when the process terminates, instead of the correct return address being popped off the stack into the program counter, the program counter is filled with the address of the malicious code, which is duly executed, with the same execution privileges as the subverted daemon process. This code can be used to create a back door to allow the attacker to log in and perform other operations at his leisure.
Those skilled in the art will appreciate that there are many variations on this basic theme, not all of which involve overwriting the return address on the stack. Other code pointers may be overwritten, such as function pointers passed as parameters in C. These attacks have one thing in common, however. They all rely on replacing a valid code pointer with a pointer to the attacker's code. The subverted pointer is then loaded into the program counter in place of the legitimate pointer that it replaces, and the malicious code is executed.
Stack-protection approaches have met with limited success. These approaches attempt to prevent overwriting critical areas on the stack where code addresses might be found, or to detect such overwriting attempts. While effective on some buffer overflow attacks (until attackers find a work-around, which they have often done), simply protecting the stack is an incomplete solution at best.
Conventional approaches overlook the fundamental problem. An attacker can stage these attacks because the program counter can be made to point to arbitrary locations. The conventional approaches fail to protect the values loaded into the program counter.